Columbia Kermit/kermit.zip/newsgroups/misc.19951130-19960209/[e-mail] _Wed Jan 3 03:22:06 1996.msg

Internet Message Format | 2020-01-01 | 6KB

Return-Path: [e-mail]
Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id DAA28524 for <kermit.misc@watsun>; Wed, 3 Jan 1996 03:22:04 -0500 (EST)
Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id DAA27850 for kermit.misc@watsun; Wed, 3 Jan 1996 03:22:03 -0500 (EST)
Path: news.columbia.edu!news.cs.columbia.edu!pipeline!psinntp!psinntp!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: The Future (was Re: Connecting to the Same Site Multiple Times)
Message-ID: <[e-mail]>
Date: 2 Jan 96 20:09:56 MDT
References: <4bcrfp$[e-mail]> <4bt2qs$[e-mail]> <4ccmsk$[e-mail]>
Organization: Utah State University
Lines: 105

In article <4ccmsk$[e-mail]>, [e-mail] (David A. Johns) writes:
> In <[e-mail]>, [e-mail] (Joe Doupnik) wrote:
>
> #   > Well, I think my vote would go for more functionality in the
> #   > scrollback buffers (mark and save, search, buffer input while
> #   > viewing the buffer, etc.) and a real plain-text session log
> #   > (and yes, I have read the .bwr).
> #
> #         I guess you mean full editing, and hence a reasonably
> #   competant full screen editor to match.
>
> Heavens, no.  I say what I mean and mean what I say.  I've never heard
> of an editable scrollback buffer, but I do find searching and blocking
> for copy very useful.

    Yes, I understand. But that's only one side of the operation. The
other is where to put the cut material and what happens to material into
whose midst the information goes. And undoing actions, and spiffing up
items, plus the inevitable search part of things, and... This is a camel
sniffing the canvas apparatus.
    I'm not stonewalling, really, but I've been along paths of this
kind many times.

> #   The session log is plain-text if that's all the host sends to
> #   us. Which means it sends a line of text followed by CR/LF, and
> #   no cursor steering, screen embellishments (bold, reverse
> #   video, etc), whatnot that make up full screen work rather than
> #   glass-tty work. Otherwise our screen is likely decorated
> #   semi-randomly as the cursor is moved here and there, and thus
> #   what we see isn't the way things arrive or logged.
>
> But most other comm programs I've seen save the buffer as plain text,
> even if it came through as vtxxx.  I can see some value to being able
> to replay the original, especially when there was a lot of screen
> manipulation.  But if I can't have both, I'd rather have the plain
> text log.

    Have you considered this approach (which is a designed-in capability):
SET PRINTER filename, Connect, when wishing to capture material press
CONTROL-PRINTSCRN, see PRN on the status line meaning printing is active,
press again to toggle off. This is DEC controller printing (not transparent
printing). And that means (quoting from MSK distribution file msvibm.vt):

 Control-PrtSc   PRTSCN        Toggle  on/off copying of received text to
                               printer, "PRN" shows on far right of mode
                               line when activated.



 CSI Pn i    MC        Printer controls (Media Copy)
            Pn
            0    Print whole Screen
            4    Exit printer controller (transparent print)
            5    Enter printer controller (transparent print)

Transparent printing sends all output, except the CSI 4 i termination string,
to the printer and not the screen, uses an 8-bit channel if no parity so NUL
and DEL will be seen by the printer and by the termination recognizer code,
and all translation and character set selections are bypassed.

 CSI ? Pn i    MC        DEC Printer controls (Media Copy)
            Pn
            1    Print line containing cursor
            4    Exit autoprint (stop echoing to printer)
            5    Enter autoprint (echo screen chars to printer)

Autoprint prints a final display line only when the cursor is moved off the
line by an autowrap or LF, FF,    or VT (otherwise do not print the line).


> #         ? MSK does not run UART chips with hardware parity.
> #   Hardware parity is a nice way of not communicating due to
> #   differences at each end. MSK uses parity in software and it is
> #   highly forgiving during terminal emulation (SET DISPLAY 7/8
> #   etc). Furthermore, during file transfers MSK automatically
> #   determines parity as much as is possible, and switches to it
> #   with a message. I can add code to probe the UART for existing
> #   parity, if that would really do a lot of good.
>
> Well, I can't imagine that there are many systems out there like the
> one I have to deal with.  It was apparently installed and abandoned
> under some Texas Instruments contract, and whether the dial-up line
> was set at 7o1 by perverse design or by accident, I don't know.  But
> while the file transfer mechanism will indeed notice the problem, the
> emulator won't.  Most people who tried this system had given up
> because they either couldn't log in or their input was mangled, until
> I stumbled upon the problem.  No, it's probably not worth changing
> now.  I just though that since you do notice some characteristics of
> the comm port, why not all of them?

    Because parity on serial ports is worthless, in my opinon, and
it is often the source of user confusion as you have just indicated.

> #         Wishlists are always welcomed, even though only portions
> #   are possible to include in the programs.
>
> Glad to hear it.  What's the best place to deliver them?

    You can try right here, where other readers can comment too.
Alternatives include to Columbia and to me directly. But let's not make a
large production over each item because there are already too few hours in
each day.
    Joe D.

> David Johns